Date: Wed, 14 Sep 94 04:30:02 PDT From: Advanced Amateur Radio Networking Group Errors-To: TCP-Group-Errors@UCSD.Edu Reply-To: TCP-Group@UCSD.Edu Precedence: Bulk Subject: TCP-Group Digest V94 #202 To: tcp-group-digest TCP-Group Digest Wed, 14 Sep 94 Volume 94 : Issue 202 Today's Topics: ax25 linux implementation? (8 msgs) Cross compile NOS with gcc? Mail failure TCP-Group Digest V94 #197 (fwd) (2 msgs) TEKK prices Send Replies or notes for publication to: . Subscription requests to . Problems you can't solve otherwise to brian@ucsd.edu. Archives of past issues of the TCP-Group Digest are available (by FTP only) from UCSD.Edu in directory "mailarchives". We trust that readers are intelligent enough to realize that all text herein consists of personal comments and does not represent the official policies or positions of any party. Your mileage may vary. So there. ---------------------------------------------------------------------- Date: Tue, 13 Sep 1994 07:34:25 -0700 From: brian@nothing.ucsd.edu (Brian Kantor) Subject: ax25 linux implementation? To: tcp-group@ucsd.edu I believe that I'd do AX.25 a different way than is being discussed. I'd like to have an AX.25 routing table. Each port would have an AX.25 'quality' or 'precedence' value assigned to it. Whenever a station is heard, an entry is made in the axrt table for that station, weighted with the 'precedence' of the interface from which the station was heard, and timestamped so that it can be expired. It would be possible to include digipeater chains in the table for the places where they are necessary. A utility would exist to enter stations into the table manually, and to flag appropriate entries as unexpireable. One interface could also be designated the default for stations whose callsign/ssid don't appear in the table at all. Packets to be sent from any socket or protocol to the AX.25 layer would be routed according to this table. Higher-level protocols such as ARP therefore don't need to know interface names. The ARP table, therefore, need only resolve the IP address to a hardware address and type, where the type is either Ether or AX25, and the address is the 48-bit Etheraddr or the 6.5 byte AX25 callsign. The AX25 and Ether ARP tables can be separate or combined. Personally, I'd do them separate. This also means that there should be an AX25 pseudo-device. The routing at the IP level would resolve to a device (Ethernet, PPP, SLIP, ENCAP, or AX25), and those that need it (Ethernet, AX25) would do ARP. The AX.25 pseudo-device could also handle digipeating if you want to. If you're going to do Net/Rom, that should be a pseudo-device with its own routing table. Again, if an IP address resolves to a net/rom pseudo-device, then the net/rom pseudo-device would route it to the AX.25 pseudo-device, which would in turn ship it off to the right port according to its routing table. (There should be an ARP at this point, but net/rom can't do ARP as far as I know, so it's all manual entries and n/r routing [much like RIP] in that table.) I don't believe Linux does it this way. It was what I was going to do with the BSD kernel mods, but personal matters came up and so I've turned that project over to you guys. Have fun! - Brian ------------------------------ Date: Tue, 13 Sep 1994 18:27:25 -0700 (PDT) From: Lyndon Nerenberg Subject: ax25 linux implementation? To: Brian Kantor > I'd like to have an AX.25 routing table. Each port would have an > AX.25 'quality' or 'precedence' value assigned to it. Whenever a > station is heard, an entry is made in the axrt table for that station, > weighted with the 'precedence' of the interface from which the station > was heard, and timestamped so that it can be expired. It would be > possible to include digipeater chains in the table for the places where > they are necessary. You have a potential problem with hearing a station direct and also via a digi on the same interface. This used to happen to me with NOS and would lead to asymetrical "route flapping" at the MAX (AX25) layer. In essence, I would establish a direct connect to the remote, the remote would establish the reciprical path, then I (NOS) would hear the remote via a digi, update the ARP table to use the digi path instead of direct, and the connect would go into hyperspace as the remote continued to use the direct path and NOS would respond via the digi. Mind you, this was an AX25 VC connect (between NOS and F6FBB software). If you're running IP inside of AX25 datagrams I would think that you could have the receiver ignore any MAC layer routing information on the incoming packets, as long as the destination MAC address matches something your interface is responding to. How do you handle the situation where you have a direct and one or more digi paths to the remote? The shortest path isn't necessarily the best, and this may vary with the time of day (it does here quite often). Perhaps we need to maintain a (time decayed) count of the number of sucessfully received packets for each path in the ARP tables? This isn't very reliable, though, as it is easily skewed by the traffic patterns of the sending station. --lyndon ------------------------------ Date: Tue, 13 Sep 1994 18:57:58 -0700 From: brian@nothing.ucsd.edu (Brian Kantor) Subject: ax25 linux implementation? To: lyndon@canada.unbc.edu The way you handle direct vs digi paths to stations is 1) get rid of the digi. Dynamite is good Digipeaters suck hard and really need to be gotten rid of as fast as possible. If this helps, so much the better. 2) lock the route down manually - Brian ------------------------------ Date: Wed, 14 Sep 1994 12:16:20 +0930 (CST) From: Rob Subject: ax25 linux implementation? To: tcp-group@UCSD.EDU As a side issue, has anyone succeeded in getting Linux to work on an HP Omnibook 530S ? Would make a nice mobile ip setup :-) Rob -- rob mayfield snr tech/analyst *nix/network admin asc p/l box 73 oaklands park mayfield@itd.adelaide.edu.au vk5xxx@vk5xxx.#adl.#sa.aus.oc s.aust 5046 ------------------------------ Date: Wed, 14 Sep 1994 12:54:36 +0930 (CST) From: Rob Subject: ax25 linux implementation? To: brian@nothing.ucsd.edu (Brian Kantor) *** In reply to mail from Brian Kantor, ....: > The way you handle direct vs digi paths to stations is > > 1) get rid of the digi. Dynamite is good Digipeaters suck hard and > really need to be gotten rid of as fast as possible. If this helps, so > much the better. This'll give the digi 'a larger coverage area', is this what we want ? Dozing it in might be safer ... ;-) -- rob mayfield snr tech/analyst *nix/network admin asc p/l box 73 oaklands park mayfield@itd.adelaide.edu.au vk5xxx@vk5xxx.#adl.#sa.aus.oc s.aust 5046 ------------------------------ Date: Wed, 14 Sep 1994 09:33:31 +0200 (BST) From: iialan@iifeak.swan.ac.uk (Alan Cox) Subject: ax25 linux implementation? To: brian@nothing.ucsd.edu (Brian Kantor) > The way you handle direct vs digi paths to stations is > 1) get rid of the digi. Dynamite is good Digipeaters suck hard and > really need to be gotten rid of as fast as possible. If this helps, so > much the better. > 2) lock the route down manually There is a lot to be said with living in the current world where (alas) digipeaters and flexnet and stuff need to peacefully coexist. This business of auto-routing v not auto-routing was an interesting one. I chose to make Linux bind to a port and connect via that port (ie client picks the port) because firstly I had a real situation where I needed to force ports all the time and secondly by not binding to an address the current code goes Nope! but new code can auto route. Indeed John Naylor (G4KLX) has added a route learning piece to the code but not yet the route picking part. Having a route cache is also useful for one other thing - you get a free MHEARD (or ax25 heard to ka9q'ers) list. However its done being able to run mosaic over amateur radio is nice 8) Alan ------------------------------ Date: Wed, 14 Sep 1994 06:17:50 -0400 From: "Brandon S. Allbery" Subject: ax25 linux implementation? To: tcp-group@UCSD.EDU In your message of Wed, 14 Sep 1994 12:54:36 +0930, you write: +--------------- | 1) get rid of the digi. Dynamite is good Digipeaters suck hard and +------------->8 It occurs to me that digis are about as likely to disappear as *.NA is. ++Brandon -- Brandon S. Allbery KF8NH [44.70.4.88] bsa@kf8nh.wariat.org Linux development: iBCS2, JNOS, MH ~\U Daily dreading Nehemiah Scudder^H^H^H^H^H^H^H^H^H^H^H^H^H^H^H^HRush Limbaugh ------------------------------ Date: Wed, 14 Sep 1994 05:36:11 -0500 (CDT) From: Gerald J Creager Subject: ax25 linux implementation? To: mayfield@guest.adelaide.edu.au (Rob) Rob sez: > > *** In reply to mail from Brian Kantor, ....: > > The way you handle direct vs digi paths to stations is > > > > 1) get rid of the digi. Dynamite is good Digipeaters suck hard and > > really need to be gotten rid of as fast as possible. If this helps, so > > much the better. > > This'll give the digi 'a larger coverage area', is this what we want ? > > Dozing it in might be safer ... ;-) With dynamite, you disperse it overa larger area both reducing the overall impact of the original problem, and making it harder for the EPA to figure out what it was to cite you. If you doze and bury it, it's a point source of contamination... ;-) Gerry ------------------------------ Date: Tue, 13 Sep 1994 09:40:38 -0800 (PDT) From: jmorriso@bogomips.ee.ubc.ca (John Paul Morrison) Subject: Cross compile NOS with gcc? To: tcp-group@ucsd.edu Does NOS build with gcc? Does it run properly? I'm wondering if the DJGPP or EMX (in DOS, not OS/2) compilers are usable. If they are, I don't even have to compile under DOS, because there are utils for GCC to let you cross compile under UNIX, and produce DOS .exe's. --------------------------------------------------------------------------- BogoMIPS Research Labs -- bogosity research & simulation -- VE7JPM -- jmorriso@bogomips.ee.ubc.ca ve7jpm@ve7jpm.ampr.org jmorriso@ve7ubc.ampr.org --------------------------------------------------------------------------- ------------------------------ Date: Tue, 13 Sep 94 19:57:00 edt From: Adminstrator Subject: Mail failure To: dayhub!3445a!ucsd.edu!TCP-Group@prowler.daytonoh.NCR.COM User mail received addressed to the following unknown addresses: GPPGDAYTON/GPPGPOST/lshannon ------------------------------------------------------------------------------ Return-Path: Received: from prowler.daytonoh.ncr.com by gppgpost.daytonoh.ncr.com id <2E763C5B@gppgpost.daytonoh.ncr.com>; Tue, 13 Sep 94 19:57:15 edt Received: by prowler.daytonoh.ncr.com; 13 Sep 94 13:18:21 EDT Received: by dayhub.DaytonOH.NCR.COM; 13 Sep 94 13:18:13 EDT Received: by 3445a.DaytonOH.NCR.COM; 13 Sep 94 13:17:43 EDT id AA779477717 Tue, 13 Sep 94 13:35:17 EST Date: Tue, 13 Sep 94 13:35:17 EST From: TCP-Group@ucsd.edu Message-Id: <9408137794.AA779477717@WPDSMTP.DaytonOH.NCR.COM> To: tcp-group-digest@ucsd.edu Subject: TCP-Group Digest V94 #201 Received: by ccmail from 3445a.DaytonOH.NCR.COM >From ncrhub1!ucsd.edu!owner-tcp-digest@dayhub.DaytonOH.NCR.COM X-Envelope-From: ncrhub1!ucsd.edu!owner-tcp-digest@dayhub.DaytonOH.NCR.COM Received: by 3445a.DaytonOH.NCR.COM; 13 Sep 94 13:14:36 EDT Received: by dayhub.DaytonOH.NCR.COM; 13 Sep 94 13:14:19 EDT Received: from ncrgw1 by ncrhub1.NCR.COM id ar05029; 13 Sep 94 13:13 EDT Received: by ncrgw1.NCR.COM; 13 Sep 94 12:52:01 EDT sendmail 8.6.9/UCSD-2.2-sun Tue, 13 Sep 1994 04:30:10 -0700 for tcp-digest-list Received: by ucsd.edu; id EAA01122 sendmail 8.6.9/UCSD-2.2-sun Tue, 13 Sep 1994 04:30:08 -0700 for tcp-group-ddist Message-Id: <199409131130.EAA01122@ucsd.edu> Date: Tue, 13 Sep 94 04:30:03 PDT From: Advanced Amateur Radio Networking Group Errors-To: TCP-Group-Errors@UCSD.EDU Reply-To: TCP-Group@ucsd.edu Precedence: Bulk Subject: TCP-Group Digest V94 #201 To: tcp-group-digest@ucsd.edu TCP-Group Digest Tue, 13 Sep 94 Volume 94 : Issue 201 Today's Topics: Mail failure SCC = Baycom Send Replies or notes for publication to: . Subscription requests to . Problems you can't solve otherwise to brian@ucsd.edu. Archives of past issues of the TCP-Group Digest are available (by FTP only) from UCSD.Edu in directory "mailarchives". We trust that readers are intelligent enough to realize that all text herein consists of personal comments and does not represent the official policies or positions of any party. Your mileage may vary. So there. ---------------------------------------------------------------------- Date: Mon, 12 Sep 94 11:48:00 edt From: Adminstrator Subject: Mail failure To: dayhub!3445a!ucsd.edu!TCP-Group@prowler.daytonoh.NCR.COM User mail received addressed to the following unknown addresses: GPPGDAYTON/GPPGPOST/lshannon ------------------------------------------------------------------------------ Return-Path: Received: from prowler.daytonoh.ncr.com by gppgpost.daytonoh.ncr.com id <2E747863@gppgpost.daytonoh.ncr.com>; Mon, 12 Sep 94 11:48:51 edt Received: by prowler.daytonoh.ncr.com; 12 Sep 94 11:42:14 EDT Received: by dayhub.DaytonOH.NCR.COM; 12 Sep 94 11:42:06 EDT Received: by 3445a.DaytonOH.NCR.COM; 12 Sep 94 11:42:13 EDT id AA779385538 Mon, 12 Sep 94 11:58:58 EST Date: Mon, 12 Sep 94 11:58:58 EST From: TCP-Group@ucsd.edu Message-Id: <9408127793.AA779385538@WPDSMTP.DaytonOH.NCR.COM> To: tcp-group-digest@ucsd.edu Subject: TCP-Group Digest V94 #200 Received: by ccmail from 3445a.DaytonOH.NCR.COM >From ncrhub1!ucsd.edu!owner-tcp-digest@dayhub.DaytonOH.NCR.COM X-Envelope-From: ncrhub1!ucsd.edu!owner-tcp-digest@dayhub.DaytonOH.NCR.COM Received: by 3445a.DaytonOH.NCR.COM; 12 Sep 94 11:37:40 EDT Received: by dayhub.DaytonOH.NCR.COM; 12 Sep 94 11:37:14 EDT Received: from ncrgw1 by ncrhub1.NCR.COM id aa27896; 12 Sep 94 11:33 EDT Received: by ncrgw1.NCR.COM; 12 Sep 94 11:32:25 EDT sendmail 8.6.9/UCSD-2.2-sun Mon, 12 Sep 1994 04:30:08 -0700 for tcp-digest-list Received: by ucsd.edu; id EAA24362 sendmail 8.6.9/UCSD-2.2-sun Mon, 12 Sep 1994 04:30:06 -0700 for tcp-group-ddist Message-Id: <199409121130.EAA24362@ucsd.edu> Date: Mon, 12 Sep 94 04:30:01 PDT From: Advanced Amateur Radio Networking Group Errors-To: TCP-Group-Errors@ucsd.edu Reply-To: TCP-Group@ucsd.edu Precedence: Bulk Subject: TCP-Group Digest V94 #200 To: tcp-group-digest@ucsd.edu TCP-Group Digest Mon, 12 Sep 94 Volume 94 : Issue 200 Today's Topics: autoampr ax25 linux implementation? Mail failure Send Replies or notes for publication to: . Subscription requests to . Problems you can't solve otherwise to brian@ucsd.edu. Archives of past issues of the TCP-Group Digest are available (by FTP only) from UCSD.Edu in directory "mailarchives". We trust that readers are intelligent enough to realize that all text herein consists of personal comments and does not represent the official policies or positions of any party. Your mileage may vary. So there. ---------------------------------------------------------------------- Date: Sun, 11 Sep 1994 12:20:39 -0600 From: bdale@gag.com (Bdale Garbee) Subject: autoampr To: gateways@mpg.phys.hawaii.edu, tcp-group@ucsd.edu I made a comment on one of the mailing lists the other day about having put together some bits and pieces to help automate the management of an ampr.org subnet. A couple of folks contacted me asking for copies of the code. I wrote up a README file, shar'ed and gzip'ed it all, and you can acquire it from ftp://winfree.gag.com/packet/gateways/autoampr.shar.gz Don't bother unless you've got a Unix machine nearby, it's all shell script. I hope it's useful to someone, has made my life a wee bit simpler. 73 - Bdale, N3EUA ------------------------------ Date: Mon, 12 Sep 1994 10:06:25 +0200 (BST) From: iialan@iifeak.swan.ac.uk (Alan Cox) Subject: ax25 linux implementation? To: davis@denali.realtime.ab.ca (Glenn Davis) > Thanks for the feedback on what an AX.25 bsd socket should do. Can you > tell me where to find the Linux implementation (source) ? I will model > my port after Linux. Also, there was mention of a few applications built > on this model; where might they reside? All reside on ftp.linux.org.uk:/pub/Linux/Radio. The code is derived from netccitt so you shouldn't have any trouble comparing it against your netccitt code. The tools that exist currently in the main set are call - AX.25 connect program with YAPP support axl - An AX.25 listener - spawns a program for each AX.25 connect [think of it as a dumb inetd] pms - Very crude PMS I wrote basically to prove I could rewrite AX.25 bulletins/mail into RFC822 and provide useful received from lines. Others are now working on this. axarp/axdelarp/axaddarp - original AX.25 arp manipulation. The current Linux net tools support AX.25 implicitly now so no special tools are used. listen - This won't port as it uses SOCK_PACKET (raw interface sockets) to monitor AX.25 KA9Q trace style. It's derived from the KA9Q trace routines. beacon - Send a regular beacon (dameon process) axattach - Attach an AX.25 iface (mirror of slattach) axsetcall - Set the AX.25 MAC address on an AX.25 interface mheard - List who has been recently heard. This uses the ax.25 routing table still under addition but collecting lists. On ftp.ucsd.edu you will find the source to some raw socket stuff for talking to microsat's. You'll also need the xview3 open windows toolkit to build this. Other people are working on doing BBS code, I'm currently playing with a very nice hostmode terminal for unix that I want to change to use AX.25 kernel sockets. If you have any great ideas or think I've done something a paticularly stupid way then I'm very open to suggestions. I'd rather we had one standard that works than one that works sort of, even if it means changing the Linux version of the code. > I just spent 8 hours finishing the ARP code. It appears that ARP's are > not used on point-to-point links normally. If I read the code correctly > BSDI just drops them on the floor. This causes problems since you want > the interface that the packet arrived on, and this is not available when > you dequeue the mbuf. > > How did the Linux implementation solve this? My solution was: Linux doesn't consider the interface point-to-point in AX.25 mode (only in SLIP mode). The data always happens to be available so that one never occured. axattach on a (previously) SLIP link clears the pointopoint flags. The one that was harder to fit nicely into the BSD socket semantics is the opening phase. I added a little piece of code so that the commonly seen SABM [wait] SABM UA [Connected] UA [Reset Connection, Connected] Doesn't cause a connection refused on the socket but waits until it opens properly. If data has been sent and another UA turns up then it does reset. Alan ------------------------------ Date: Mon, 12 Sep 94 06:43:00 edt From: Adminstrator Subject: Mail failure To: dayhub!3445a!ucsd.edu!TCP-Group@prowler.daytonoh.NCR.COM User mail received addressed to the following unknown addresses: GPPGDAYTON/GPPGPOST/lshannon ------------------------------------------------------------------------------ Return-Path: Received: from prowler.daytonoh.ncr.com by gppgpost.daytonoh.ncr.com id <2E7430E2@gppgpost.daytonoh.ncr.com>; Mon, 12 Sep 94 06:43:46 edt Received: by prowler.daytonoh.ncr.com; 12 Sep 94 06:37:02 EDT Received: by dayhub.DaytonOH.NCR.COM; 12 Sep 94 06:36:52 EDT Received: by 3445a.DaytonOH.NCR.COM; 12 Sep 94 06:36:55 EDT id AA779367213 Mon, 12 Sep 94 06:53:33 EST Date: Mon, 12 Sep 94 06:53:33 EST From: TCP-Group@ucsd.edu Message-Id: <9408127793.AA779367213@WPDSMTP.DaytonOH.NCR.COM> To: tcp-group-digest@ucsd.edu Subject: TCP-Group Digest V94 #199 Received: by ccmail from 3445a.DaytonOH.NCR.COM >From ncrhub1!ucsd.edu!owner-tcp-digest@dayhub.DaytonOH.NCR.COM X-Envelope-From: ncrhub1!ucsd.edu!owner-tcp-digest@dayhub.DaytonOH.NCR.COM Received: by 3445a.DaytonOH.NCR.COM; 12 Sep 94 06:33:35 EDT Received: by dayhub.DaytonOH.NCR.COM; 12 Sep 94 06:33:10 EDT Received: from ncrgw2 by ncrhub1.NCR.COM id ba07109; 12 Sep 94 6:16 EDT Received: by ncrgw2.NCR.COM; 10 Sep 94 10:12:46 EDT sendmail 8.6.9/UCSD-2.2-sun Sat, 10 Sep 1994 04:30:10 -0700 for tcp-digest-list Received: by ucsd.edu; id EAA11034 sendmail 8.6.9/UCSD-2.2-sun Sat, 10 Sep 1994 04:30:09 -0700 for tcp-group-ddist Message-Id: <199409101130.EAA11034@ucsd.edu> Date: Sat, 10 Sep 94 04:30:07 PDT From: Advanced Amateur Radio Networking Group Errors-To: TCP-Group-Errors@UCSD.EDU Reply-To: TCP-Group@ucsd.edu Precedence: Bulk Subject: TCP-Group Digest V94 #199 To: tcp-group-digest@ucsd.edu TCP-Group Digest Sat, 10 Sep 94 Volume 94 : Issue 199 Today's Topics: av023@yfn.ysu.edu ax25 linux implementation? Borland C++ 4.0x patches released Mail failure Send Replies or notes for publication to: . Subscription requests to . Problems you can't solve otherwise to brian@ucsd.edu. Archives of past issues of the TCP-Group Digest are available (by FTP only) from UCSD.Edu in directory "mailarchives". We trust that readers are intelligent enough to realize that all text herein consists of personal comments and does not represent the official policies or positions of any party. Your mileage may vary. So there. ---------------------------------------------------------------------- Date: Fri, 9 Sep 1994 23:41:36 -0400 From: av023@yfn.ysu.edu (Frederick A. Peachman) Subject: av023@yfn.ysu.edu To: tcp-group@ucsd.edu subscribe -- Fred Peachman, Brookfield Ohio av023@yfn.ysu.edu ------------------------------ Date: Fri, 9 Sep 1994 19:39:21 -0600 From: Glenn Davis Subject: ax25 linux implementation? To: tcp-group@ucsd.edu Thanks for the feedback on what an AX.25 bsd socket should do. Can you tell me where to find the Linux implementation (source) ? I will model my port after Linux. Also, there was mention of a few applications built on this model; where might they reside? I just spent 8 hours finishing the ARP code. It appears that ARP's are not used on point-to-point links normally. If I read the code correctly BSDI just drops them on the floor. This causes problems since you want the interface that the packet arrived on, and this is not available when you dequeue the mbuf. How did the Linux implementation solve this? My solution was: Receive unsolicited ARP reply, or ARP request (broadcast): - use IP routing info, or interface this AX25 address last heard on to determine interface. This could result in the wrong interface, and potentially requires storing a large number of AX25 address/interface pairs. Receive directed ARP reply: - if it was in the table (unresolved request) use it, else drop the packet. Send ARP reply: - send on interface from the arp cache (based on ARP request). Send ARP discovery: - use IP routing, last interface this AX25 heard on, or send to all interfaces with a sockaddr in the AX.25 family. The downside is that the arp table now needs an extra field for the interface. On the other hand, there is no guarantee that the same AX25 address will not be heard on more that one interface. Glenn ------------------------------ Date: Fri, 09 Sep 94 17:19:00 -0000 From: mikebw@bilow.bilow.uu.ids.net (Mike Bilow) Subject: Borland C++ 4.0x patches released To: tcp-group@ucsd.edu The following files may be of interest to NOS developers. BC4DOS32.ZIP 38K 9-05-94* How to develop 32-bit DOS apps using only Borland C++ v4's RTM. Includes src. BC4P01.ZIP 5K 9-05-94* Patch file for Borland C++ v4.00 BC4P02.ZIP 129K 9-05-94* Patch file for Borland C++ v4.00 BC4P03.ZIP 441K 9-05-94* Patch file for Borland C++ v4.00 BC4P04.ZIP 65K 9-05-94* Patch file for Borland C++ v4.00 to v4.02 These files are posted for dial-up download at N1BEE BBS, +1 401 944 8498 (to 28800 bps V.34/V.FC), but I don't know of any Internet sites. I assume they will be widely available on the Internet. N1BEE BBS is also supports Fidonet file requests to 1:323/107. -- Mike ------------------------------ Date: Fri, 09 Sep 94 11:09:00 edt From: Adminstrator Subject: Mail failure To: dayhub!3445a!ucsd.edu!TCP-Group@prowler.daytonoh.NCR.COM User mail received addressed to the following unknown addresses: GPPGDAYTON/GPPGPOST/lshannon ------------------------------------------------------------------------------ Return-Path: Received: from prowler.daytonoh.ncr.com by gppgpost.daytonoh.ncr.com id <2E707AA0@gppgpost.daytonoh.ncr.com>; Fri, 09 Sep 94 11:09:20 edt Received: by prowler.daytonoh.ncr.com; 9 Sep 94 11:04:41 EDT Received: by dayhub.DaytonOH.NCR.COM; 9 Sep 94 11:04:15 EDT Received: by 3445a.DaytonOH.NCR.COM; 9 Sep 94 11:04:47 EDT id AA779123936 Fri, 09 Sep 94 11:18:56 EST Date: Fri, 09 Sep 94 11:18:56 EST From: TCP-Group@ucsd.edu Message-Id: <9408097791.AA779123936@WPDSMTP.DaytonOH.NCR.COM> To: tcp-group-digest@ucsd.edu Subject: TCP-Group Digest V94 #198 Received: by ccmail from 3445a.DaytonOH.NCR.COM >From ncrhub1!ucsd.edu!owner-tcp-digest@dayhub.DaytonOH.NCR.COM X-Envelope-From: ncrhub1!ucsd.edu!owner-tcp-digest@dayhub.DaytonOH.NCR.COM Received: by 3445a.DaytonOH.NCR.COM; 9 Sep 94 11:03:11 EDT Received: by dayhub.DaytonOH.NCR.COM; 9 Sep 94 11:02:21 EDT Received: from ncrgw1 by ncrhub1.NCR.COM id be12293; 9 Sep 94 11:01 EDT Received: by ncrgw1.NCR.COM; 9 Sep 94 10:57:44 EDT sendmail 8.6.9/UCSD-2.2-sun Fri, 9 Sep 1994 04:30:13 -0700 for tcp-digest-list Received: by ucsd.edu; id EAA25167 sendmail 8.6.9/UCSD-2.2-sun Fri, 9 Sep 1994 04:30:11 -0700 for tcp-group-ddist Message-Id: <199409091130.EAA25167@ucsd.edu> Date: Fri, 9 Sep 94 04:30:06 PDT From: Advanced Amateur Radio Networking Group Errors-To: TCP-Group-Errors@ucsd.edu Reply-To: TCP-Group@ucsd.edu Precedence: Bulk Subject: TCP-Group Digest V94 #198 To: tcp-group-digest@ucsd.edu TCP-Group Digest Fri, 9 Sep 94 Volume 94 : Issue 198 Today's Topics: 9k6 on-air test? RE> KPC-9612 and X1J (IP routing) TCP-Group Digest V94 #197 TCP-Group Digest V94 #197 (fwd) Send Replies or notes for publication to: . Subscription requests to . Problems you can't solve otherwise to brian@ucsd.edu. Archives of past issues of the TCP-Group Digest are available (by FTP only) from UCSD.Edu in directory "mailarchives". We trust that readers are intelligent enough to realize that all text herein consists of personal comments and does not represent the official policies or positions of any party. Your mileage may vary. So there. ---------------------------------------------------------------------- Date: Thu, 8 Sep 1994 21:42:43 -0700 (PDT) From: jerry@tr2.com (Jerome Kaidor) Subject: 9k6 on-air test? To: tcp-group@ucsd.edu Is there anybody on this list who's in the the San Francisco Bay area and could help me with an on-the-air test of my new 9600-baud packet station on 2M? It does receive, but there's nothing much happening on the local 9k6 frequency. Just one station that keeps sending: N6LDL-1>ID:Network node (#LGNODE) When I try to connect to it, nothing happens. I assume its a NET/ROM node, or somesuch. But then, I have no idea if my transmit level is reasonable. Is there, perhaps, an AX25 BBS or two on 9k6? My goal is to get the thing working on 70CM tcp/ip, but it seemed simpler to get the ax25 stuff working first.... - Jerry Kaidor, KF6VB ------------------------------ Date: Thu, 8 Sep 1994 20:46:36 -0600 From: ve6eei@ve6eei.ampr.ab.ca (Evan E. Idler, Edmonton, AB [192.75.200.5]) Subject: RE> KPC-9612 and X1J (IP routing) To: tcp-group@ucsd.edu It was mentioned that it would be nice to have the kpc-9612 to route ip on a remote site, as a dual port router. Well, I had a nice talk with Ruth Hull at the Radio Amateur Of Canada Convention last month, and this topic came up. Well it seems, that If enought write The president of KANTRONICS, they will port X1J over to run on it. However if there is not enought people requesting it, they will not be undertaking the project. SO, IF YOU WANT IT YOU ALL HAVE TO TELL THEM THAT YOU WANT IT!!!!!!!!!!! I beleive the person to Write your letter to is: Karl Medcalf Kantronics Co., Inc. 1202 E. 23rd Street Lawrence, KS 66046 So write him, tell him how much you like your new KPC-9612, but how much you would also like it to run X1J code. If enough people ask, they will do it. 73 EVAN ======================================================================= Evan E. Idler | Of All The Things I've Lost ve6eei@ve6eei.ampr.ab.ca | In Life, I Miss My MIND The Edmonton, Alberta, Canada | Most!!! Amateur Packet Radio Station VE6EEI [192.75.200.5] ======================================================================= ------------------------------ Date: Thu, 8 Sep 1994 10:20:54 -0800 (PDT) From: jmorriso@bogomips.ee.ubc.ca (John Paul Morrison) Subject: TCP-Group Digest V94 #197 To: TCP-Group@UCSD.EDU > > Date: Wed, 7 Sep 1994 20:05:09 -0600 > From: Glenn Davis > Subject: ax25 on bsd > To: tcp-group@ucsd.edu > > I have started the work to complete Brian Kantors AX25/KISS driver on BSDI. > The stuff that is missing is: arp, good routing, and the socket interface > (via pr_usrreq hook in the protocol switch table). > > Has anyone given much thought to the semantics of how sockets should be > used when talking ax.25? The IP stuff will remain pretty much the same, Why don't you follow what the Linux AX.25 sockets do, since that is already a working implementation. > but I want to keep the ability to connect to non-ip packet bbs's. The > intent is to run a modified telnetd (using the ax25 protocols) to allow > incoming connections. I have patched BSD rlogind to work on a Linux AX.25 socket. It's not really rlogin any more, as I've stripped out most of what's not needed for AX.25, I just used it because it handled all the pty and login shell stuff. I looked at telnetd for this, but it's too bloated and difficult for me to figure out what to disable or fake for AX.25. A linux program called axl listens on the AX.25 interface. When it gets a connection, it forks off ax.rlogind, then goes back to listening, and that gives you a login: prompt. You can login and get a shell prompt. When you login you have to stty a few things (I think /bin/login changes the tty modes, so even if I did set the line mode in ax.rlogind, login would just change it back). I should change ax.rlogind to use skeylogin to prompt for passwords. (which reminds me: does anyone have an Skey available for an HP48 or other small calculator, so you can calculate the response to the challenge without doing it by hand or installing skey on every machine you visit) It's quite horrible really, but it works. I don't think 1200bps packet with a line at a time entry is useable for much with a login shell, but instead of starting login, you could start up a bbs process, or some mail stuff. > > glenn/ve6rsx > --------------------------------------------------------------------------- BogoMIPS Research Labs -- bogosity research & simulation -- VE7JPM -- jmorriso@bogomips.ee.ubc.ca ve7jpm@ve7jpm.ampr.org jmorriso@rflab.ee.ubc.ca --------------------------------------------------------------------------- ------------------------------ Date: Fri, 9 Sep 1994 11:38:39 +0200 (BST) From: iialan@iifeak.swan.ac.uk (Alan Cox) Subject: TCP-Group Digest V94 #197 (fwd) To: tcp-group@ucsd.edu In-Reply-To: from "John Paul Morrison" at Se p 8, 94 10:20:54 am > Why don't you follow what the Linux AX.25 sockets do, since that is > already a working implementation. This seems sensible as we have nice tools and I'm also open to alterations as suggested. The AX.25 socket layer basically works as follows under Linux SOCK_RAW gives raw AX.25 access where the type of socket is the AX.25 PID. Datagrams or VC delivered raw and you fix it. SOCK_DGRAM UI AX.25 protocol frames. Marked with the AX.25 type SOCK_SEQPACKET AX.25 connection mode. Since its derived from the BSD netccitt LAPB code the same hacks to it should work roughly for BSD networking. It's got other stuff like setting window, t1,n2,t3 via setsockopt. Following that core setup would make most stuff portable (which as we all know is good news). Alan ------------------------------ End of TCP-Group Digest V94 #198 ****************************** ------------------------------ End of TCP-Group Digest V94 #199 ****************************** ------------------------------ End of TCP-Group Digest V94 #200 ****************************** ------------------------------ Date: Tue, 13 Sep 94 12:28:48 EST From: csmall@acacia.itd.uts.edu.au (c.small-acacia-ele-student-90064116) Subject: SCC = Baycom To: tcp-group@ucsd.edu (TCP-group relay) G'day All, I was looking at the NOS scc drivers to see if they could be used for the PackeTwin (result: i think so but it's beyond me!) and noticed that they had as one of the options for the hardware as Baycom. Is this the same baycom as the one where you get something like a AM7910 chip that takes the CTS/RTS lines as data? The reason is that there is a SCC driver in Linux, there is neither a driver for PackeTwin or baycom modems (yet). I'm very keen to ditch the nos gateway and let the Linux have direct access to the ports, rather than through the SLIP link. - Craig vk2xlz -- // /\ | | | | | ... Craig Small [44.136.8.58] ... ... ||==|--|====|====|===|==|=| ... INTERNET: csmall@acacia.itd.uts.edu.au \\ \/ | | | | | ... AMPR : VK2XLZ@VK2XSB.NSW.AUS.OC ------------------------------ End of TCP-Group Digest V94 #201 ****************************** ------------------------------ Date: Wed, 14 Sep 1994 02:36:17 -0700 From: Phil Karn Subject: TCP-Group Digest V94 #197 (fwd) To: iialan@iifeak.swan.ac.uk >The AX.25 socket layer basically works as follows under Linux I haven't kept up with this stuff, so I have a few esoteric questions based on my own implementation experience in NOS. How are digipeaters specified? Separate routing table? Socket option? What happens when you try to open two AX.25 connections between the same pair of machines? This isn't permitted by AX.25 (there being no port field) so something has to give. At the very least, you wouldn't be able to access someone else's server at the same time they're accessing yours. And suppose somebody logs into your server and then disappears. You'd be kept from initiating a connection to their machine indefinitely, unless you enable some sort of $#@!! keepalive mechanism. IMHO, even if you're only nominally interested in one active session at a time, port muxing mechanisms like those in TCP are very useful in lessening the impact of these sorts of half-open connections. Instead of a difficult choice between channel-wasting keepalives and having to deal manually with a half-open connection each time it occurs, you merely waste a little memory on an idle TCP control block. Big deal. :-) That's why I've never been particularly excited about using AX.25 as a transport protocol, especially in a multitasking OS that assumes a "real" transport protocol like TCP. I understand why people are doing it -- to make their systems maximally accessible. But the real goal should be to make it unnecessary by putting TCP into the hands of as many end users as possible. Phil ------------------------------ Date: Wed, 14 Sep 1994 10:43:41 +0200 (BST) From: iialan@iifeak.swan.ac.uk (Alan Cox) Subject: TCP-Group Digest V94 #197 (fwd) To: karn@unix.ka9q.ampr.org (Phil Karn) > How are digipeaters specified? Separate routing table? Socket option? For AX.25 connections they are part of the sockaddr_ax25 structure. This I can see causing fun in BSD which suffers the old 14 byte address problem unless you rebuild from source. IPng will mean this has to get fixed in BSD anyway. The IP layer uses entries added to the arp table with digipeated paths (as per KA9Q), but doesn't work with them as Linux < the current pre 1.3.0 doesn't believe in devices with variable length headers. The new stuff does it right. > What happens when you try to open two AX.25 connections between the > same pair of machines? This isn't permitted by AX.25 (there being no > port field) so something has to give. At the very least, you wouldn't EBUSY. Everything you say here about AX.25 being non ideal goes as true. AX.25 T3 polls seem to ensure this mostly works and BBS systems have survived with the limitation 8) > That's why I've never been particularly excited about using AX.25 as a > transport protocol, especially in a multitasking OS that assumes a > "real" transport protocol like TCP. I understand why people are doing > it -- to make their systems maximally accessible. But the real goal > should be to make it unnecessary by putting TCP into the hands of as > many end users as possible. A lot of the world isn't that TCP aware so AX.25 is useful. *BSD and Linux have also changed where Unix like systems fit in for many people in that they are very much client machines using AX.25 to talk to BBS systems [should we insert the word 'legacy' here 8)]. For showing people _why_ TCP/IP over radio is neat binary ftp and Mosaic normally does the trick.. Alan ------------------------------ Date: Tue, 13 Sep 94 09:07 PDT From: bruce@pixar.com (Bruce Perens) Subject: TEKK prices To: tcp-group@ucsd.edu I recently ordered another TEKK transceiver. No surprise - with the fall of the dollar of late prices have risen. For those unfamilliar with the TEKK radios, they are 450 MHz 2-watt fixed-frequency units that run on 10-12 volts and fit in a shirt pocket. Here's what they are charging: T-Net Micro (KS-900) 2 watt transceiver in cabinet: 119.90 Transmitter only in cabinet: 92.90 Receiver only in cabinet: 84.90 Custom Frequency Charges per Crystal: 12.50 T-Net Mini (the Micro works better for 9600) 2 watt transmitter in "Omni-can": 129.90 T-Mode Mini 2 watt transceiver with 4800 modem: 229.90 M-48 4800 baud modem in "Omni-can": 114.90 4800 baud modem bare PCB: 114.90 TEKK's phone numbers are: Voice 1-800-521-8355, FAX 1-816-746-1093. A KS-900 transceiver and crystals now costs $150 by the time you're done with shipping. This makes the $150 synthesized Ramsey kit become attractive for the same application. Of course there's the time investment of assembling and debugging the Ramsey kit, and you need a shielded box (which comes with the TEKK). Bruce Perens ------------------------------ Date: Tue Sep 13 19:57:30 EST 1994 From: postmaster@prowler.daytonoh.NCR.COM Received: by prowler.daytonoh.ncr.com; 13 Sep 94 13:18:21 EDT Received: by dayhub.DaytonOH.NCR.COM; 13 Sep 94 13:18:13 EDT Received: by 3445a.DaytonOH.NCR.COM; 13 Sep 94 13:17:43 EDT id AA779477717 Tue, 13 Sep 94 13:35:17 EST Date: Tue, 13 Sep 94 13:35:17 EST From: TCP-Group@ucsd.edu Message-Id: <9408137794.AA779477717@WPDSMTP.DaytonOH.NCR.COM> To: tcp-group-digest@ucsd.edu Subject: TCP-Group Digest V94 #201 Received: by ccmail from 3445a.DaytonOH.NCR.COM >From ncrhub1!ucsd.edu!owner-tcp-digest@dayhub.DaytonOH.NCR.COM X-Envelope-From: ncrhub1!ucsd.edu!owner-tcp-digest@dayhub.DaytonOH.NCR.COM Received: by 3445a.DaytonOH.NCR.COM; 13 Sep 94 13:14:36 EDT Received: by dayhub.DaytonOH.NCR.COM; 13 Sep 94 13:14:19 EDT Received: from ncrgw1 by ncrhub1.NCR.COM id ar05029; 13 Sep 94 13:13 EDT Received: by ncrgw1.NCR.COM; 13 Sep 94 12:52:01 EDT sendmail 8.6.9/UCSD-2.2-sun Tue, 13 Sep 1994 04:30:10 -0700 for tcp-digest-list Received: by ucsd.edu; id EAA01122 sendmail 8.6.9/UCSD-2.2-sun Tue, 13 Sep 1994 04:30:08 -0700 for tcp-group-ddist Message-Id: <199409131130.EAA01122@ucsd.edu> Date: Tue, 13 Sep 94 04:30:03 PDT From: Advanced Amateur Radio Networking Group Errors-To: TCP-Group-Errors@UCSD.EDU Reply-To: TCP-Group@ucsd.edu Precedence: Bulk Subject: TCP-Group Digest V94 #201 To: tcp-group-digest@ucsd.edu TCP-Group Digest Tue, 13 Sep 94 Volume 94 : Issue 201 Today's Topics: Mail failure SCC = Baycom Send Replies or notes for publication to: . Subscription requests to . Problems you can't solve otherwise to brian@ucsd.edu. Archives of past issues of the TCP-Group Digest are available (by FTP only) from UCSD.Edu in directory "mailarchives". We trust that readers are intelligent enough to realize that all text herein consists of personal comments and does not represent the official policies or positions of any party. Your mileage may vary. So there. ---------------------------------------------------------------------- Date: Mon, 12 Sep 94 11:48:00 edt From: Adminstrator Subject: Mail failure To: dayhub!3445a!ucsd.edu!TCP-Group@prowler.daytonoh.NCR.COM User mail received addressed to the following unknown addresses: GPPGDAYTON/GPPGPOST/lshannon ------------------------------------------------------------------------------ Return-Path: Received: from prowler.daytonoh.ncr.com by gppgpost.daytonoh.ncr.com id <2E747863@gppgpost.daytonoh.ncr.com>; Mon, 12 Sep 94 11:48:51 edt Received: by prowler.daytonoh.ncr.com; 12 Sep 94 11:42:14 EDT Received: by dayhub.DaytonOH.NCR.COM; 12 Sep 94 11:42:06 EDT Received: by 3445a.DaytonOH.NCR.COM; 12 Sep 94 11:42:13 EDT id AA779385538 Mon, 12 Sep 94 11:58:58 EST Date: Mon, 12 Sep 94 11:58:58 EST From: TCP-Group@ucsd.edu Message-Id: <9408127793.AA779385538@WPDSMTP.DaytonOH.NCR.COM> To: tcp-group-digest@ucsd.edu Subject: TCP-Group Digest V94 #200 Received: by ccmail from 3445a.DaytonOH.NCR.COM >From ncrhub1!ucsd.edu!owner-tcp-digest@dayhub.DaytonOH.NCR.COM X-Envelope-From: ncrhub1!ucsd.edu!owner-tcp-digest@dayhub.DaytonOH.NCR.COM Received: by 3445a.DaytonOH.NCR.COM; 12 Sep 94 11:37:40 EDT Received: by dayhub.DaytonOH.NCR.COM; 12 Sep 94 11:37:14 EDT Received: from ncrgw1 by ncrhub1.NCR.COM id aa27896; 12 Sep 94 11:33 EDT Received: by ncrgw1.NCR.COM; 12 Sep 94 11:32:25 EDT sendmail 8.6.9/UCSD-2.2-sun Mon, 12 Sep 1994 04:30:08 -0700 for tcp-digest-list Received: by ucsd.edu; id EAA24362 sendmail 8.6.9/UCSD-2.2-sun Mon, 12 Sep 1994 04:30:06 -0700 for tcp-group-ddist Message-Id: <199409121130.EAA24362@ucsd.edu> Date: Mon, 12 Sep 94 04:30:01 PDT From: Advanced Amateur Radio Networking Group Errors-To: TCP-Group-Errors@ucsd.edu Reply-To: TCP-Group@ucsd.edu Precedence: Bulk Subject: TCP-Group Digest V94 #200 To: tcp-group-digest@ucsd.edu TCP-Group Digest Mon, 12 Sep 94 Volume 94 : Issue 200 Today's Topics: autoampr ax25 linux implementation? Mail failure Send Replies or notes for publication to: . Subscription requests to . Problems you can't solve otherwise to brian@ucsd.edu. Archives of past issues of the TCP-Group Digest are available (by FTP only) from UCSD.Edu in directory "mailarchives". We trust that readers are intelligent enough to realize that all text herein consists of personal comments and does not represent the official policies or positions of any party. Your mileage may vary. So there. ---------------------------------------------------------------------- Date: Sun, 11 Sep 1994 12:20:39 -0600 From: bdale@gag.com (Bdale Garbee) Subject: autoampr To: gateways@mpg.phys.hawaii.edu, tcp-group@ucsd.edu I made a comment on one of the mailing lists the other day about having put together some bits and pieces to help automate the management of an ampr.org subnet. A couple of folks contacted me asking for copies of the code. I wrote up a README file, shar'ed and gzip'ed it all, and you can acquire it from ftp://winfree.gag.com/packet/gateways/autoampr.shar.gz Don't bother unless you've got a Unix machine nearby, it's all shell script. I hope it's useful to someone, has made my life a wee bit simpler. 73 - Bdale, N3EUA ------------------------------ Date: Mon, 12 Sep 1994 10:06:25 +0200 (BST) From: iialan@iifeak.swan.ac.uk (Alan Cox) Subject: ax25 linux implementation? To: davis@denali.realtime.ab.ca (Glenn Davis) > Thanks for the feedback on what an AX.25 bsd socket should do. Can you > tell me where to find the Linux implementation (source) ? I will model > my port after Linux. Also, there was mention of a few applications built > on this model; where might they reside? All reside on ftp.linux.org.uk:/pub/Linux/Radio. The code is derived from netccitt so you shouldn't have any trouble comparing it against your netccitt code. The tools that exist currently in the main set are call - AX.25 connect program with YAPP support axl - An AX.25 listener - spawns a program for each AX.25 connect [think of it as a dumb inetd] pms - Very crude PMS I wrote basically to prove I could rewrite AX.25 bulletins/mail into RFC822 and provide useful received from lines. Others are now working on this. axarp/axdelarp/axaddarp - original AX.25 arp manipulation. The current Linux net tools support AX.25 implicitly now so no special tools are used. listen - This won't port as it uses SOCK_PACKET (raw interface sockets) to monitor AX.25 KA9Q trace style. It's derived from the KA9Q trace routines. beacon - Send a regular beacon (dameon process) axattach - Attach an AX.25 iface (mirror of slattach) axsetcall - Set the AX.25 MAC address on an AX.25 interface mheard - List who has been recently heard. This uses the ax.25 routing table still under addition but collecting lists. On ftp.ucsd.edu you will find the source to some raw socket stuff for talking to microsat's. You'll also need the xview3 open windows toolkit to build this. Other people are working on doing BBS code, I'm currently playing with a very nice hostmode terminal for unix that I want to change to use AX.25 kernel sockets. If you have any great ideas or think I've done something a paticularly stupid way then I'm very open to suggestions. I'd rather we had one standard that works than one that works sort of, even if it means changing the Linux version of the code. > I just spent 8 hours finishing the ARP code. It appears that ARP's are > not used on point-to-point links normally. If I read the code correctly > BSDI just drops them on the floor. This causes problems since you want > the interface that the packet arrived on, and this is not available when > you dequeue the mbuf. > > How did the Linux implementation solve this? My solution was: Linux doesn't consider the interface point-to-point in AX.25 mode (only in SLIP mode). The data always happens to be available so that one never occured. axattach on a (previously) SLIP link clears the pointopoint flags. The one that was harder to fit nicely into the BSD socket semantics is the opening phase. I added a little piece of code so that the commonly seen SABM [wait] SABM UA [Connected] UA [Reset Connection, Connected] Doesn't cause a connection refused on the socket but waits until it opens properly. If data has been sent and another UA turns up then it does reset. Alan ------------------------------ Date: Mon, 12 Sep 94 06:43:00 edt From: Adminstrator Subject: Mail failure To: dayhub!3445a!ucsd.edu!TCP-Group@prowler.daytonoh.NCR.COM User mail received addressed to the following unknown addresses: GPPGDAYTON/GPPGPOST/lshannon ------------------------------------------------------------------------------ Return-Path: Received: from prowler.daytonoh.ncr.com by gppgpost.daytonoh.ncr.com id <2E7430E2@gppgpost.daytonoh.ncr.com>; Mon, 12 Sep 94 06:43:46 edt Received: by prowler.daytonoh.ncr.com; 12 Sep 94 06:37:02 EDT Received: by dayhub.DaytonOH.NCR.COM; 12 Sep 94 06:36:52 EDT Received: by 3445a.DaytonOH.NCR.COM; 12 Sep 94 06:36:55 EDT id AA779367213 Mon, 12 Sep 94 06:53:33 EST Date: Mon, 12 Sep 94 06:53:33 EST From: TCP-Group@ucsd.edu Message-Id: <9408127793.AA779367213@WPDSMTP.DaytonOH.NCR.COM> To: tcp-group-digest@ucsd.edu Subject: TCP-Group Digest V94 #199 Received: by ccmail from 3445a.DaytonOH.NCR.COM >From ncrhub1!ucsd.edu!owner-tcp-digest@dayhub.DaytonOH.NCR.COM X-Envelope-From: ncrhub1!ucsd.edu!owner-tcp-digest@dayhub.DaytonOH.NCR.COM Received: by 3445a.DaytonOH.NCR.COM; 12 Sep 94 06:33:35 EDT Received: by dayhub.DaytonOH.NCR.COM; 12 Sep 94 06:33:10 EDT Received: from ncrgw2 by ncrhub1.NCR.COM id ba07109; 12 Sep 94 6:16 EDT Received: by ncrgw2.NCR.COM; 10 Sep 94 10:12:46 EDT sendmail 8.6.9/UCSD-2.2-sun Sat, 10 Sep 1994 04:30:10 -0700 for tcp-digest-list Received: by ucsd.edu; id EAA11034 sendmail 8.6.9/UCSD-2.2-sun Sat, 10 Sep 1994 04:30:09 -0700 for tcp-group-ddist Message-Id: <199409101130.EAA11034@ucsd.edu> Date: Sat, 10 Sep 94 04:30:07 PDT From: Advanced Amateur Radio Networking Group Errors-To: TCP-Group-Errors@UCSD.EDU Reply-To: TCP-Group@ucsd.edu Precedence: Bulk Subject: TCP-Group Digest V94 #199 To: tcp-group-digest@ucsd.edu TCP-Group Digest Sat, 10 Sep 94 Volume 94 : Issue 199 Today's Topics: av023@yfn.ysu.edu ax25 linux implementation? Borland C++ 4.0x patches released Mail failure Send Replies or notes for publication to: . Subscription requests to . Problems you can't solve otherwise to brian@ucsd.edu. Archives of past issues of the TCP-Group Digest are available (by FTP only) from UCSD.Edu in directory "mailarchives". We trust that readers are intelligent enough to realize that all text herein consists of personal comments and does not represent the official policies or positions of any party. Your mileage may vary. So there. ---------------------------------------------------------------------- Date: Fri, 9 Sep 1994 23:41:36 -0400 From: av023@yfn.ysu.edu (Frederick A. Peachman) Subject: av023@yfn.ysu.edu To: tcp-group@ucsd.edu subscribe -- Fred Peachman, Brookfield Ohio av023@yfn.ysu.edu ------------------------------ Date: Fri, 9 Sep 1994 19:39:21 -0600 From: Glenn Davis Subject: ax25 linux implementation? To: tcp-group@ucsd.edu Thanks for the feedback on what an AX.25 bsd socket should do. Can you tell me where to find the Linux implementation (source) ? I will model my port after Linux. Also, there was mention of a few applications built on this model; where might they reside? I just spent 8 hours finishing the ARP code. It appears that ARP's are not used on point-to-point links normally. If I read the code correctly BSDI just drops them on the floor. This causes problems since you want the interface that the packet arrived on, and this is not available when you dequeue the mbuf. How did the Linux implementation solve this? My solution was: Receive unsolicited ARP reply, or ARP request (broadcast): - use IP routing info, or interface this AX25 address last heard on to determine interface. This could result in the wrong interface, and potentially requires storing a large number of AX25 address/interface pairs. Receive directed ARP reply: - if it was in the table (unresolved request) use it, else drop the packet. Send ARP reply: - send on interface from the arp cache (based on ARP request). Send ARP discovery: - use IP routing, last interface this AX25 heard on, or send to all interfaces with a sockaddr in the AX.25 family. The downside is that the arp table now needs an extra field for the interface. On the other hand, there is no guarantee that the same AX25 address will not be heard on more that one interface. Glenn ------------------------------ Date: Fri, 09 Sep 94 17:19:00 -0000 From: mikebw@bilow.bilow.uu.ids.net (Mike Bilow) Subject: Borland C++ 4.0x patches released To: tcp-group@ucsd.edu The following files may be of interest to NOS developers. BC4DOS32.ZIP 38K 9-05-94* How to develop 32-bit DOS apps using only Borland C++ v4's RTM. Includes src. BC4P01.ZIP 5K 9-05-94* Patch file for Borland C++ v4.00 BC4P02.ZIP 129K 9-05-94* Patch file for Borland C++ v4.00 BC4P03.ZIP 441K 9-05-94* Patch file for Borland C++ v4.00 BC4P04.ZIP 65K 9-05-94* Patch file for Borland C++ v4.00 to v4.02 These files are posted for dial-up download at N1BEE BBS, +1 401 944 8498 (to 28800 bps V.34/V.FC), but I don't know of any Internet sites. I assume they will be widely available on the Internet. N1BEE BBS is also supports Fidonet file requests to 1:323/107. -- Mike ------------------------------ Date: Fri, 09 Sep 94 11:09:00 edt From: Adminstrator Subject: Mail failure To: dayhub!3445a!ucsd.edu!TCP-Group@prowler.daytonoh.NCR.COM User mail received addressed to the following unknown addresses: GPPGDAYTON/GPPGPOST/lshannon ------------------------------------------------------------------------------ Return-Path: Received: from prowler.daytonoh.ncr.com by gppgpost.daytonoh.ncr.com id <2E707AA0@gppgpost.daytonoh.ncr.com>; Fri, 09 Sep 94 11:09:20 edt Received: by prowler.daytonoh.ncr.com; 9 Sep 94 11:04:41 EDT Received: by dayhub.DaytonOH.NCR.COM; 9 Sep 94 11:04:15 EDT Received: by 3445a.DaytonOH.NCR.COM; 9 Sep 94 11:04:47 EDT id AA779123936 Fri, 09 Sep 94 11:18:56 EST Date: Fri, 09 Sep 94 11:18:56 EST From: TCP-Group@ucsd.edu Message-Id: <9408097791.AA779123936@WPDSMTP.DaytonOH.NCR.COM> To: tcp-group-digest@ucsd.edu Subject: TCP-Group Digest V94 #198 Received: by ccmail from 3445a.DaytonOH.NCR.COM >From ncrhub1!ucsd.edu!owner-tcp-digest@dayhub.DaytonOH.NCR.COM X-Envelope-From: ncrhub1!ucsd.edu!owner-tcp-digest@dayhub.DaytonOH.NCR.COM Received: by 3445a.DaytonOH.NCR.COM; 9 Sep 94 11:03:11 EDT Received: by dayhub.DaytonOH.NCR.COM; 9 Sep 94 11:02:21 EDT Received: from ncrgw1 by ncrhub1.NCR.COM id be12293; 9 Sep 94 11:01 EDT Received: by ncrgw1.NCR.COM; 9 Sep 94 10:57:44 EDT sendmail 8.6.9/UCSD-2.2-sun Fri, 9 Sep 1994 04:30:13 -0700 for tcp-digest-list Received: by ucsd.edu; id EAA25167 sendmail 8.6.9/UCSD-2.2-sun Fri, 9 Sep 1994 04:30:11 -0700 for tcp-group-ddist Message-Id: <199409091130.EAA25167@ucsd.edu> Date: Fri, 9 Sep 94 04:30:06 PDT From: Advanced Amateur Radio Networking Group Errors-To: TCP-Group-Errors@ucsd.edu Reply-To: TCP-Group@ucsd.edu Precedence: Bulk Subject: TCP-Group Digest V94 #198 To: tcp-group-digest@ucsd.edu TCP-Group Digest Fri, 9 Sep 94 Volume 94 : Issue 198 Today's Topics: 9k6 on-air test? RE> KPC-9612 and X1J (IP routing) TCP-Group Digest V94 #197 TCP-Group Digest V94 #197 (fwd) Send Replies or notes for publication to: . Subscription requests to . Problems you can't solve otherwise to brian@ucsd.edu. Archives of past issues of the TCP-Group Digest are available (by FTP only) from UCSD.Edu in directory "mailarchives". We trust that readers are intelligent enough to realize that all text herein consists of personal comments and does not represent the official policies or positions of any party. Your mileage may vary. So there. ---------------------------------------------------------------------- Date: Thu, 8 Sep 1994 21:42:43 -0700 (PDT) From: jerry@tr2.com (Jerome Kaidor) Subject: 9k6 on-air test? To: tcp-group@ucsd.edu Is there anybody on this list who's in the the San Francisco Bay area and could help me with an on-the-air test of my new 9600-baud packet station on 2M? It does receive, but there's nothing much happening on the local 9k6 frequency. Just one station that keeps sending: N6LDL-1>ID:Network node (#LGNODE) When I try to connect to it, nothing happens. I assume its a NET/ROM node, or somesuch. But then, I have no idea if my transmit level is reasonable. Is there, perhaps, an AX25 BBS or two on 9k6? My goal is to get the thing working on 70CM tcp/ip, but it seemed simpler to get the ax25 stuff working first.... - Jerry Kaidor, KF6VB ------------------------------ Date: Thu, 8 Sep 1994 20:46:36 -0600 From: ve6eei@ve6eei.ampr.ab.ca (Evan E. Idler, Edmonton, AB [192.75.200.5]) Subject: RE> KPC-9612 and X1J (IP routing) To: tcp-group@ucsd.edu It was mentioned that it would be nice to have the kpc-9612 to route ip on a remote site, as a dual port router. Well, I had a nice talk with Ruth Hull at the Radio Amateur Of Canada Convention last month, and this topic came up. Well it seems, that If enought write The president of KANTRONICS, they will port X1J over to run on it. However if there is not enought people requesting it, they will not be undertaking the project. SO, IF YOU WANT IT YOU ALL HAVE TO TELL THEM THAT YOU WANT IT!!!!!!!!!!! I beleive the person to Write your letter to is: Karl Medcalf Kantronics Co., Inc. 1202 E. 23rd Street Lawrence, KS 66046 So write him, tell him how much you like your new KPC-9612, but how much you would also like it to run X1J code. If enough people ask, they will do it. 73 EVAN ======================================================================= Evan E. Idler | Of All The Things I've Lost ve6eei@ve6eei.ampr.ab.ca | In Life, I Miss My MIND The Edmonton, Alberta, Canada | Most!!! Amateur Packet Radio Station VE6EEI [192.75.200.5] ======================================================================= ------------------------------ Date: Thu, 8 Sep 1994 10:20:54 -0800 (PDT) From: jmorriso@bogomips.ee.ubc.ca (John Paul Morrison) Subject: TCP-Group Digest V94 #197 To: TCP-Group@UCSD.EDU > > Date: Wed, 7 Sep 1994 20:05:09 -0600 > From: Glenn Davis > Subject: ax25 on bsd > To: tcp-group@ucsd.edu > > I have started the work to complete Brian Kantors AX25/KISS driver on BSDI. > The stuff that is missing is: arp, good routing, and the socket interface > (via pr_usrreq hook in the protocol switch table). > > Has anyone given much thought to the semantics of how sockets should be > used when talking ax.25? The IP stuff will remain pretty much the same, Why don't you follow what the Linux AX.25 sockets do, since that is already a working implementation. > but I want to keep the ability to connect to non-ip packet bbs's. The > intent is to run a modified telnetd (using the ax25 protocols) to allow > incoming connections. I have patched BSD rlogind to work on a Linux AX.25 socket. It's not really rlogin any more, as I've stripped out most of what's not needed for AX.25, I just used it because it handled all the pty and login shell stuff. I looked at telnetd for this, but it's too bloated and difficult for me to figure out what to disable or fake for AX.25. A linux program called axl listens on the AX.25 interface. When it gets a connection, it forks off ax.rlogind, then goes back to listening, and that gives you a login: prompt. You can login and get a shell prompt. When you login you have to stty a few things (I think /bin/login changes the tty modes, so even if I did set the line mode in ax.rlogind, login would just change it back). I should change ax.rlogind to use skeylogin to prompt for passwords. (which reminds me: does anyone have an Skey available for an HP48 or other small calculator, so you can calculate the response to the challenge without doing it by hand or installing skey on every machine you visit) It's quite horrible really, but it works. I don't think 1200bps packet with a line at a time entry is useable for much with a login shell, but instead of starting login, you could start up a bbs process, or some mail stuff. > > glenn/ve6rsx > --------------------------------------------------------------------------- BogoMIPS Research Labs -- bogosity research & simulation -- VE7JPM -- jmorriso@bogomips.ee.ubc.ca ve7jpm@ve7jpm.ampr.org jmorriso@rflab.ee.ubc.ca --------------------------------------------------------------------------- ------------------------------ Date: Fri, 9 Sep 1994 11:38:39 +0200 (BST) From: iialan@iifeak.swan.ac.uk (Alan Cox) Subject: TCP-Group Digest V94 #197 (fwd) To: tcp-group@ucsd.edu In-Reply-To: from "John Paul Morrison" at Se p 8, 94 10:20:54 am > Why don't you follow what the Linux AX.25 sockets do, since that is > already a working implementation. This seems sensible as we have nice tools and I'm also open to alterations as suggested. The AX.25 socket layer basically works as follows under Linux SOCK_RAW gives raw AX.25 access where the type of socket is the AX.25 PID. Datagrams or VC delivered raw and you fix it. SOCK_DGRAM UI AX.25 protocol frames. Marked with the AX.25 type SOCK_SEQPACKET AX.25 connection mode. Since its derived from the BSD netccitt LAPB code the same hacks to it should work roughly for BSD networking. It's got other stuff like setting window, t1,n2,t3 via setsockopt. Following that core setup would make most stuff portable (which as we all know is good news). Alan ------------------------------ End of TCP-Group Digest V94 #198 ****************************** ------------------------------ End of TCP-Group Digest V94 #199 ****************************** ------------------------------ End of TCP-Group Digest V94 #200 ****************************** ------------------------------ Date: Tue, 13 Sep 94 12:28:48 EST From: csmall@acacia.itd.uts.edu.au (c.small-acacia-ele-student-90064116) Subject: SCC = Baycom To: tcp-group@ucsd.edu (TCP-group relay) G'day All, I was looking at the NOS scc drivers to see if they could be used for the PackeTwin (result: i think so but it's beyond me!) and noticed that they had as one of the options for the hardware as Baycom. Is this the same baycom as the one where you get something like a AM7910 chip that takes the CTS/RTS lines as data? The reason is that there is a SCC driver in Linux, there is neither a driver for PackeTwin or baycom modems (yet). I'm very keen to ditch the nos gateway and let the Linux have direct access to the ports, rather than through the SLIP link. - Craig vk2xlz -- // /\ | | | | | ... Craig Small [44.136.8.58] ... ... ||==|--|====|====|===|==|=| ... INTERNET: csmall@acacia.itd.uts.edu.au \\ \/ | | | | | ... AMPR : VK2XLZ@VK2XSB.NSW.AUS.OC ------------------------------ End of TCP-Group Digest V94 #201 ****************************** ------------------------------ End of TCP-Group Digest V94 #202 ******************************